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The Rendezvous and Proximity Operations Program (RPOP) is a laptop com- 
puter-based relative navigation tool and piloting aid that was developed during 
the Space Shuttle program. RPOP displays a graphical representation of the rel- 
ative motion between the target and chaser vehicles in a rendezvous, proximity 
operations and capture scenario. After being used in over 60 Shuttle rendezvous 
missions, some of the RPOP display concepts have become recognized as a min- 
imum standard for cockpit displays for monitoring the rendezvous task. To sup- 
port International Space Station (ISS) based crews in monitoring incoming visit- 
ing vehicles, RPOP has been modified to allow crews to compare the Cygnus 
visiting vehicle’s onboard navigated state to processed range measurements 
from an ISS-based, crew-operated Hand Held Lidar sensor. This paper will dis- 
cuss the display concepts of RPOP that have proven useful in performing and 
monitoring rendezvous and proximity operations. 

INTRODUCTION 
<Add introduction^ 

RPOP DESCRIPTION 

RPOP is a rendezvous and proximity operations situational awareness tool. It is a Windows 
application, tailored for the IBM/Lenovo Thinkpad laptop computers used by NASA. RPOP ac- 
quires visiting vehicle and target vehicle state information (position, velocity, attitude, and atti- 
tude rates) from its host vehicle and graphically displays the relative state between the two vehi- 
cles. The display can include a plot of the relative motion from multiple measurement sources, 
display of vehicle and target attitudes, time-graduated coasting trajectory predictions, and piloting 
overlays tailored to the demands of the mission ( approach corridors, hold points, etc). RPOP also 
contains an input interface to the Hand Held Lidar (HHL) sensor. 

RPOP HISTORY 


Initial development of requirements for RPOP occurred in 1 992 specifically to support Orbiter 
docking to Mir and ISS. The concept was to develop an application that runs on laptop computer 
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in the Orbiter cockpit to provide the pilot relative trajectory information not available on the Or- 
biter’s main computers. The primary purpose of RPOP was to help the Orbiter pilot meet opera- 
tional flight constraints by providing a common location to view and evaluate data from multiple 
sensors. 

Once the requirements were approved, the RPOP development team used an existing program, 
Payload Bay (PLBAY), as a baseline that was developed by astronaut Rick Hieb and already cer- 
tified to run on the laptop computers in the Orbiter cockpit. PLBAY had flown on STS-49 - it 
allowed the crew to manually enter raw radar data and camera angle data to compute and display 
in-plane motion of the Orbiter relative to the rendezvous target. This capability was functional, 
but very constraining from a crew workload perspective. With Rick Hieb’s consent, the RPOP 
team selected PLBAY as the foundation for RPOP development. 

The evolution of PLBAY into RPOP began by implementing two extremely important re- 
quirements for navigation: 1) ability to process continuous payload-bay laser data, and 2) ability 
to process data from the Orbiter’s General Purpose Computer (GPC). STS-51 was the first de- 
velopmental flight of the payload-bay laser known as the Trajectory Control Sensor (TCS) and 
the GPC data extraction program known as PCDecom (later renamed WinDecom). The RPOP 
team modified PLABAY to add an interface to accept and process these two new sources of data 
via serial connection and performing a flight test on STS-5 1 . This flight test of RPOP proved that 
multiple sources of data could be processed, thereby alleviating the previously heavy workload 
required to manually input data. The successful flight test of RPOP on STS-51 proved the feasi- 
bility of displaying navigation data on a laptop computer, while minimizing crew workload. 

RPOP was flown and used by Orbiter pilots on every rendezvous mission since STS-5 1 in 
1992 until Orbiter retirement in 2010. This included <??> docking missions with Mir and ISS, as 
well as <??> small satellite deploy and retrieve missions. Several modifications were made to 
RPOP during this time, including improved displays, upgrades for new laptop operating systems, 
and guidance capability to provide the pilot with suggested translational hand controller inputs. 

WHY RPOP FOR ISS? 

The first block of the Orbital Cygnus vehicle did not meet crew monitoring requirements due 
to its sensor suite. Cygnus had three identical LIDAR sensors, but the fact that they are identical 
caused concern over whether all three sensors are susceptible to a common mode failure. NASA 
required an independent source of range and range rate. The Crew Monitoring Working Group 
performed trade studies on how to address this issue and proposed to use a Hand Held Lidar 
(HHL) sensor, which had previously been used during rendezvous for the Space Shuttle program 
and had been transferred to the ISS. 
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While the HHL provides an independent source of range and range rate, by itself it does not 
meet crew interface requirements for ISS. The display on the back of the HHL unit displays the 
range and range rate in units of feet and feet per second, whereas the ISS requirement is for all 
crew displays to be in Systeme Internationale (SI) units of meters and meters per second. 

The Crew Monitoring Working Group proposed using RPOP with the HHL to satisfy the in- 
dependent range/range rate requirement. Modifications would be necessary to convert RPOP’s 
display to SI units and to make the comparison between the HHL measurements and Cygnus’s 
onboard navigation easier to interpret. To provide data for this comparison, RPOP would need to 
be modified to enable it to read data from the ISS’s telemetry system. It was found in the trade 
study that even with these modifications, adapting RPOP to a new role held advantages over de- 
veloping an all-new program to compare the HHL data with the onboard navigation data. 

First, RPOP already has an interface to the HHL that allows the HHL to input its measurement 
via serial cable. This capability was used extensively for the Space Shuttle program, as the HHL 
was the backup sensor to the Orbiter’s main rendezvous sensor for ISS missions. The interface 
allows the crew to connect the HHL to the laptop with an RS-232 serial cable, and the RPOP 
software will automatically display, process, and record HHL measurement data whenever the 
trigger is pulled. 

Another advantage to using RPOP is that, once the modifications are made to allow the input 
of data from the ISS telemetry system, all of the graphics and display concepts that made RPOP 
valuable during the piloting of a Space Shuttle rendezvous (such as the relative motion plot, pre- 
dicted trajectory, etc) are immediately operational and available. These displays present data dif- 
ferently than the existing rendezvous monitoring displays and make a good supplement to the 
required displays. 

A final advantage to RPOP is that ISS crews that have previously flown on Space Shuttle 
missions are familiar with the RPOP user interface, reducing the training necessary to use it in a 
new application. 
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RPOP FOR SPACE SHUTTLE 

For the Space Shuttle program, RPOP was used as an aid during the piloting task for rendez- 
vous missions. RPOP processed and displayed data from multiple data sources to improve the 
situational awareness of the rendezvous pilot. 

RPOP read GN&C data from the Shuttle Orbiter’s GPC such as onboard state vector esti- 
mates, measurements from the rendezvous radar and Inertial Measurement Unit (IMU), the Tra- 
jectory Control Sensor (a scanning LIDAR) and the Fland Field Lidar. RPOP processed the data 
from all of these sources and displayed the resulting trajectory from each source on its relative 
motion plot. This allowed the user to easily compare the results from each measurement source 
to assess the health of the navigation estimate and to determine if any of the measurement sources 
were providing unreliable results. 

RPOP also included an extended Kalman filter to process measurements from the Trajectory 
Control Sensor (TCS). The TCS Navigation filter (TCS NAV) allowed RPOP to improve the 
accuracy of its state estimate well enough to satisfy the rate envelope for the docking mechanism. 

RPOP also included some rendezvous guidance capability. Based on the navigation data from 
either the onboard state vector or TCS NAV, the guidance provided the crew with piloting sug- 
gestions to fly a more propellant-efficient trajectory. 

In addition, RPOP was run in NASA’s Mission Control Center using space-to-ground teleme- 
try as an input. This gave ground operators insight into what information and cues the crew was 
using to decide how to fly their approaches. 

RPOP FOR ISS 

A key difference in RPOP’s role on the International Space Station is that RPOP would be 
used as a monitoring aid rather than as a piloting aid. Despite this difference, the functionality of 
the display is largely the same, with the same displays of relative motion, attitude, trajectory pre- 
dictions, and static overlays. The key difference that tailors RPOP specifically for the monitoring 
capability is the transformation of the Cygnus relative state into an equivalent HHL range meas- 
urement for comparison. In dedicated part of the display, the HHL Measurement and RPOP’s 
transformed estimate are both displayed along with the absolute and percentage differences be- 
tween the two. Color coding indicates whether or not the difference is within pre-set margins of 
error. 

RPOP Requirements 

The modifications to RPOP had to satisfy the following requirements: 

• RPOP shall run on a Lenovo Thinkpad T61p model laptop. These are the laptops that are 
used by the crew onboard the ISS. This was a difference from the laptop model that was 
used for the Space Shuttle program, especially in the screen size. The layout of the in- 
formation of the screen had to be changed to be compatible with the aspect ratio of the 
T61p. 

• The units of all data on the display shall be in SI units, due to ISS cockpit display re- 
quirements. 

• The RPOP program shall read data from the ISS telemetry system. 

• RPOP shall calculate and display a comparison between the HHL measurement and the 
visiting vehicle’s state vector. 

• RPOP shall correctly operate while the visiting vehicle is closer than 1 km. 
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HHL PERFORMANCE 


1. Computation of the Cygnus state vector-derived range rate 


Consulting figure 1, we see that the position vector from the HHL to the aim point on Cygnus 
is 


(LVLH) r (LVLH) , ( LVLH ) _ (LVLH) 

HHL to aimpt\Cygnus * ISS CG to Cygnus CG * Cygnus CG to aimpt * ISS CG to HHL 

All of the vectors in the previous equation are expressed in the LVLH reference frame. Note 
that the last two vectors on the right-hand side are fixed in their respective bodies; therefore, ne- 
glecting small attitude errors we have 8r HHLtoaimMCygnus = 5r iss cg to c yg nus cg- Then it follows that 

C O v ( r mu ( Q aimpt\Cygnus) C 0 V ( Yjgg ( Q !t) Cygnus CG ) 
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Figure 1 : More HHL measurement geometry 

It can be shown that the range rate compatible with the HHL range rate measurements, but de- 
rived from the Cygnus data is approximately 


L HI!. | Cygnus 


(LVLH) # (LVLH) 

Cygnus eg wrt ISS eg 1 HHL to aimpt\Cygnus 


' HHL to aimpt\Cygnus 
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Here, the notation “|Cygnus” indicates that the computation is done with the Cygnus data. 

We give a comparison of the range rate that would be measured by the Cygnus LIDAR track- 
ing reflector #7, and the range rate of Cygnus with respect to the HHL’s location at the cupola. 
Figure 2 shows this comparison from 30 m to the capture point. This shows why we transform the 
Cygnus-computed range rate to a range rate compatible with the HHL measurement. 
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Figure 2: Nominal range rate from 30 m to capture 

2. An expression for the variance of the Cygnus-derived range rate 


Henceforth, we suppress the “|Cygnus” designation for brevity (except when needed for clari- 
ty). Also, we denote the CG-to-CG state by simply v cg _ cg , and r HHLtoaimpt is replaced by r HHL . From 
the last equation in the preceding section we find that the error in the range rate estimated from 
the Cygnus state vectors can be expressed as 


dr. 




HHL 


HHL\Cygnus 


dc 
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HHL 
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After computing the partial derivatives (defined as row vectors), substituting into the previous 
equation, and computing the variance of the error we obtain 
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The preceding expression is the variance of the Cygnus filter’s estimate of the range rate to the 
HHL. 

The error in the HHL/DT range rate measurement derived by RPOP from the HHL range 
measurements is independent of the error in the estimate derived from the Cygnus state vector. 
Denote the error in the measurement by Sr HHL DT . The variance of the difference of the two esti- 
mates is 

Var (Si" d iff) = ^ aV (^HHL\Cygnus) + ^ aV (^HHL IDt) 

The variance of the error in the HHL/DT calculation was estimated on 3 1 of the last 32 flights 
of the Space Shuttle to the ISS (ref. 1). The variance differs between HHL operators, but the en- 
velope of values is known. Not surprisingly, the variance is a function of range. 

3. HHL/DT accuracy 

Thus far, we have not discussed the accuracy of the HHL measurements. We did extensive 
analysis of the performance of the HHL after many Space Shuttle flights. There is no guarantee 
that the performance of the HHL will be the same with Cygnus as our experience with shuttle 
astronauts shooting the HHL at the ISS. Considering that Cygnus is a much smaller target, it may 
be more difficult to obtain a laser return at long range. 

Also, accuracy of the HHL on Space Shuttle flights varied considerably from operator to oper- 
ator. Figures 3-6 each show two histograms. The bottom histogram shows all of the data, and the 
top histogram shows the data with the 5 percent most extreme points from each tail deleted (the 
same as in the tables). Each dot in each histogram represents the standard deviation of the 
HHL/DT for a single flight at the given range. 

Histogram of Std. Dev. of HHL/DT Histogram of Std. Dev. of HHL/DT 

31 flights to ISS; Range > 305 m 31 flights to ISS; 183 m < Range < 305 m 




Standard deviation of HHL/DT estimate (m/sec) Standard deviation of HHL/DT estimate (m/sec) 
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Histogram of Std. Dev. of HHL/DT Histogram of Std. Dev. of HHL/DT 

31 flights to ISS; 91 m < Range < 183 m 31 flights to ISS; Range < 91 m 
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Standard deviation of HHL/DT estimate (m/sec) Standard deviation of HHL/DT estimate (m/sec) 

Figures 3-6: Fiistograms of the standard deviation of FIFIL/DT at various ranges 

4. Other considerations in developing thresholds 

Data on the Cygnus display will be colored yellow if the Cygnus-derived estimate differs from 
the HHL estimate by a threshold. If the threshold is too small, the crew will be frequently given 
what amounts to an alarm, when actually there is no degradation of the Cygnus navigation (i.e., a 
false alarm, corresponding to a Type I error in statistics). If the threshold is too large, use of HHL 
on ISS will have little capability to detect an error in the Cygnus navigation (i.e., a false negative, 
corresponding to a Type II error in statistics). The goal is to choose a threshold that has adequate 
capability to detect a Cygnus navigation error, but does not lead to frequent false alarms. We ex- 
pect that the threshold should be a function of range. 

The operator data presented in this report are taken from HHL measurements of the very large 
ISS target taken from the Space Shuttle Orbiter. Very large errors are obtained when the operator 
was not aiming at the assumed point on the ISS. Cygnus is much smaller than the ISS, being 
about 5 m in length and 3 m in diameter. An “error” caused by a change in aim point cannot be 
greater than the size of Cygnus. 

If the operator executes a 5-second trigger pull with the HHL, the average change in range 
would be half the nominal range rate x 5 sec. At 1 km, the nominal range rate is -1.6 m/sec. 
Therefore, this effect contributes up to 4 m. We assume that the HHL instrument noise may be 1 
m. An analysis showed a worst-case range error is about 9.3 m when relative GPS is the source of 
navigation. Adding these error sources, we obtain 1.5 m (size) + 4 m (movement) + 9.35 m (Cyg- 
nus and HHL RSS noise) = 14.85 m. We round this to 15 m. At close range, the three-standard 
deviation poor operator may see a difference of just less than 3 m. We choose this for the thresh- 
old inside a range of 100 m. The threshold varies linearly between ranges of 500 m and 100 m. 
Therefore, we arrive at the range threshold shown in figure 7 below. 

Now we turn to the range rate threshold. As with the range data, the operator data used to de- 
rive the expected difference between the HHL and Cygnus estimates are of HHL measurements 
from the Orbiter to the ISS. Because HHL/DT = (range, - range, _i)/A/, large range errors affect 
the HHL/DT calculation. Cygnus is about 5 m in length. But even if the HHL operator were to 
obtain a return from opposite ends of the vehicle, the difference in range would be small until 
very close to capture. This leads us to think that the results based on HHL measurements of ISS 
from the Orbiter are very conservative. Adding 0.02 m/sec (3a) Cygnus error, 0.04 m/sec point- 


ing error (2 m/50 sec), and a maximum 0.1 m/sec bias at long range results in a sum of 0.16 
m/sec. The preceding rationale does not account for additional operator error. Doubling the 0.16 
m/sec and rounding, we arrive at 0.3 m/sec. Setting the threshold to 0.03 m/sec at 100 m and var- 
ying linearly between 0.3 m/sec at 500 m we arrive at the threshold function shown in figure 8. 


Recommended 

Range Difference Threshold vs. Range 



Range (m) 


Figure 7: Range threshold vs. range 
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Figure 8: Range rate threshold vs. range 


SIMULATION AND TESTING 

An essential element required for the development, certification, and ultimately, the opera- 
tional success of RPOP is a computer simulation test bed capable of feeding RPOP realistic data 
for operational relevant test scenarios. The Interactive Control and Dynamics Simulation (ICDS) 
is the primary simulation test bed used in the development and testing of RPOP. ICDS is a high- 
fidelity two-vehicle earth orbital GN&C simulation capable of simulating visiting vehicle rendez- 
vous and proximity operations with the ISS. ICDS contains sensor models, effector models, and 
functional GN&C software allowing accurate simulation of mission specific approach and separa- 
tion trajectories. A very detailed FIFIL performance model was developed in ICDS to support 
RPOP development for the Space Shuttle program. This FIFIL model has been verified with flight 
data from numerous Space Shuttle flights. This same I II IL model was used for RPOP for ISS de- 
velopment and testing, where its simulated location instead was moved to be based onboard the 
ISS tracking and measuring the visiting vehicle. ICDS also includes serial and Ethernet network 
communication for sending both the simulated I II IL data as well as the Cygnus onboard GN&C 
telemetry data required by RPOP. 

For RPOP certification, a series of functional, performance and interface test cases were de- 
veloped in ICDS for each required scenario. In the actual testing, ICDS serial and network com- 
munication cables were connected to RPOP while the test was being executed. During this time, 
RPOP is running just as it would onboard the ISS, taking in and processing telemetry from Cyg- 
nus, the ISS, and measurement data from the FIFIL. In this setup, RPOP does not know it is con- 
nected to a simulation, and responds to data and user interaction inputs just like it would in flight. 


OPERATIONAL CONCEPT 
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The ISS crew will be using several tools to gather information about the relative trajectory of 
the approaching visiting vehicle. RPOP will supplement these tools to provide additional infor- 
mation that can be used to confirm the position of the visiting vehicle. 

RPOP receives relative state (position an velocity) data continuously via telemetry from the 
visiting vehicle. This data is processed and displayed graphically on an LVLH relative motion 
plot and updated continuously. The relative motion plot depicts several important pieces of in- 
formation, including: 1) the current position and attitude of the visiting vehicle relative to the ISS, 
2) the history of relative position creating a relative trajectory, 3) a prediction of future positions 
otherwise known as predicted trajectory in one-minute increments, 4) reference trajectory and 
constraint overlays, and 5) digital relative position and velocity data. The ISS crew can quickly 
look at this display and ascertain the current state of the visiting vehicle relative to trajectory con- 
straints. 

<Decide how to describe/organize paragraphs for generic RPOP capability versus Cygnus- 
specific capability using HHL.> 

For Cygnus, RPOP will run on a laptop computer positioned in the cupola of the ISS attached 
via RS-232 serial cable to the hand-held LIDAR (F1FIL). <Add an ISS figure showing the cupo- 
la.> An ISS crewmember will periodically aim and shoot the FIFIL through the cupola window at 
the approaching Cygnus vehicle. The range and range-rate measurements from the FIFIL will be 
sent to RPOP and processed. The Cygnus-computed relative navigation state will be sent to 
RPOP via PCS-DAS. RPOP will display the Cygnus-computed relative range and range-rate and 
the FIFIL-derived relative range and range-rate so that the ISS crewmember can compare the two 
sources of data. <Add Rdot window display from RPOP.> <Add figure of Cygnus relative trajec- 
tory.> 

The ISS flight rules are unchanged with the addition of RPOP to the toolset used by the ISS 
crew for monitoring. RPOP is considered situational awareness only - it is not safety or mission 
critical. While, the ISS crew will use information from RPOP to supplement other tools and data, 
the crew will not make an abort call based on RPOP information only. However, if RPOP pro- 
vided information that indicated the visiting vehicle was out of positional limits, the crew could 
contact the ground controllers to inquire. 

<Add paragraph about RWS and other tools used to monitor.> 


References 


1. Clark, F. D., “HHL Range Rate Performance Analysis for STS- 135,” SSV-1 1-009, GCD-11- 
490, 14 Jul 2011. 


10 



